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1.  Introduction 

In  this  report1  we  describe  four  alternative  syntactic  forms  for  the  object-oriented  language  fl,  described  in 
our  View  of  Object-Oriented  Programming  (Naval  Postgraduate  School  Computer  Science  Dept.  Tech. 
Rept.  NPS52-8S-001,  Feb.  198S).  Additional  information  on  a  prototype  implementation  of  fl  can  be 
found  in  Heins  M-  McArthur’s  Dctign  and  Implementation  of  an  Object-Oriented,  Production- Rule  Inter¬ 
preter  (Naval  Postgraduate  School  Master’s  Thesis,  Dec.  1984). 

It  must  be  emphasised  that  these  notations  are  all  different  concrete  representations  for  the  same 
abstract  language.  Thus,  for  example,  rules  could  be  entered  in  one  form  and  displayed  in  another.  This 
permits  different  users  (or  the  same  user  at  different  points  in  time)  to  look  at  a  program  in  different 


The  first  syntactic  form,  fl|,  uses  a  predicate  logic  style.  It  is  also  the  simplest  to  parse.  The  second 
and  third  styles  (fl3  and  0»)  have  a  stylised  natural  language  format.  As  a  result  they  are  less  compact, 
but  more  readable  to  computer-naive  users.  The  fourth  form,  0«,  drops  the  linear  syntax  of  the  other 
three,  and  adopts  a  two-dimensional  format  based  on  the  idea  of  a  form.  It  is  the  least  compact,  but  most 
amenable  to  use  by  computer-naive  users. 

We  describe  each  of  these  forms  in  the  body  of  this  report,  and  illustrate  the  forms  with  a  simple 
example.  A  formal  grammar  for  each  format  appears  in  the  Appendices. 


1.  Work  reported  herein  we*  supported  is  part  by  the  Office  of  Naval  Research  under  contract  number  N0001t-Si-2tOS7. 


1.  First  Form 


I 

The  first  form,  fl|  is  based  on  a  predicate-logic  style  notation.  It  will  look  familiar  to  readers  acquainted 
with  logic  programming  languages  and  production  rule  systems.  The  basic  construct  is  the  rule,  which 
has  the  form 

cause  =■*  effeet 

The  cause  describes  a  possible  situation  in  a  space  of  objects  connected  by  relations.  If  that  situation 
holds,  then  the  rule  may  be  applied,  which  means  that  the  actions  described  by  its  effect  part  will  be  per¬ 
formed.  Rules  are  executed  indivisibly,  which  means  that  it  is  guaranteed  that  the  situation  still  holds 
when  the  actions  are  performed. 

There  is  normally  no  order  implied  between  rules;  they  can  be  tested  in  any  order.  However,  rules  can 
be  connected  by  the  word  else  when  a  particular  order  must  be  imposed: 

cause  |  =*  effect j 
else  cause  ,  =>  effect j 

else  cause.  =»  effect * 

In  this  case,  the  second  and  succeeding  rules  are  tried  only  when  the  preceding  rules  have  failed. 

The  cause  part  of  a  rule  describes  a  situation  in  terms  of  one  or  more  conditions,  which  represent  the 
presence  or  absence  of  relationships  between  objects: 

condition  i,  condition  j,  .  .  . ,  condition* 

All  of  these  conditions  must  be  satisfied  before  a  rule  can  be  applied. 

A  condition  for  testing  for  the  presence  of  a  tuple  in  a  relationship  has  the  form: 

primary  (  pattern],  pattern t,  .  .  .  ,  pattern*  ) 

The  primary  is  an  expression  (usually  just  an  identifier)  that  evaluates  to  a  relation.  The  following  list  of 
patterns  defines  a  tuple  pattern.  Each  pattern  in  the  list  can  be  either  an  free  (i.e.,  undefined)  variable,  or 
an  expression  containing  no  free  (i.e.,  only  bound)  variables.  An  expression  is  evaluated  during  the 


matching  process,  and  matches  a  value  equal  to  the  result  of  its  evaluation.  A  free  variable  will  match 
any  value,  but  becomes  bound  to  that  value  during  the  matching  process.  The  special  free  variable  ' ’ 
can  be  used  to  match  anything  without  binding  a  variable  name. 

A  condition  for  testing  for  the  absence  of  a  tuple  from  a  relationship  has  the  form: 

->  primary  (  pattern  i,  pattern  j,  .  .  .  ,  pattern*  ) 

This  condition  succeeds  only  if  there  is  not  a  tuple  of  the  specified  form  in  the  relation  that  is  the  value  of 
the  primary. 

Finally,  as  a  convenience  we  permit  cancel  conditions: 

*primary  (  pattern ,,  pattern  j,  .  .  .  ,  pattern*  ) 

This  tests  for  the  presence  of  a  tuple  of  the  specified  form,  just  as  the  first  kind  of  condition,  but  it  has  a 
side  effect  of  deleting  that  tuple  if  the  rule  is  applied.  Although,  this  could  be  programmed  explicitly,  the 
situation  is  common  enough  that  it  is  important  to  reflect  it  in  the  notation. 

The  effect  part  of  a  rule  is  composed  of  a  sequence  of  transactions : 

transaction ,,  transaction  t,  .  .  .  ,  transaction. 

These  transactions  can  be  performed  in  any  order  or  in  parallel.  The  transactions  are  of  four  kinds:  asser¬ 
tions,  denials,  calls  and  sequential  blocks. 

An  assertion  is  a  transaction  of  the  form: 

primary  (  expression  t,  expression  expression*  ) 

Its  effect  is  to  add  to  the  relation  that  is  the  value  of  the  primary  the  tuple  <  Vt,  Vt,  .  .  .  ,  V*  >,  where 
each  V,  is  the  value  of  expression  .  Typically  these  expressions  contain  variables  that  were  bound  in  the 
cause  part  of  the  rule. 

A  denial  has  the  form  of  an  assertion  preceded  by  a  negation  sign: 

-•primary  (  expression t,  expression  t,  .  .  .  ,  expression*  ) 

Its  effect  is  to  delete  the  specified  tuple  from  the  specified  relation.  If  this  relation  does  not  contain  this 
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tuple,  then  an  error  condition  holds. 


A  call  is  a  transaction  of  the  form: 

primary  {  expression  t,  expression  ,  expression,  } 

Its  purpose  is  a  form  of  synchronous  communication  performed  by  sending  a  message  through  one  relation, 
and  waiting  for  a  reply  to  be  returned  through  another  relation.  For  example,  the  call 

P{E,F) 

has  the  effect  of  performing  the  assertion 

P(a,E,F) 

Here  a  is  a  newly  generated  relation  that  will  be  used  for  receiving  the  reply.  This  assertion  presumably 
requests  some  actions  to  be  performed  by  other  rules  (which  are  watching  P ).  When  the  actions  are  com¬ 
pleted,  an  acknowledgment  or  reply  will  be  placed  in  the  a  relation,  which  permits  the  calling  rule  to 
complete.  Note  that  rules  containing  calls  in  their  effect  parts  are  not  considered  indivisible. 

The  last  kind  of  transaction  is  a  sequential  block,  which  has  the  form: 

{  statement  lt  statement 3;  •  •  •  ;  statement,  } 

The  effect  of  this  construct  is  to  execute  the  component  statements  in  order.  A  statement  is  simply  a 
rule,  simple  or  compound,  with  the  additional  characteristic  that  its  cause  part  (and  the  **)  can  be  omit¬ 
ted.  This  reflects  the  fact  that  in  a  sequential  block  the  performance  of  actions  may  be  conditioned  solely 
on  the  performance  of  the  preceding  statements. 

A  user  normally  interacts  with  an  fl  system  by  typing  statements.  Thus  the  form  of  an  fi  terminal 
session  is: 

statement 
statement  j; 

statement ; 

Many  of  the  statements  typed  interactively  are  isolated  effects  containing  a  single  call.  For  example,  to 


define  ‘Contents’  to  be  a  new  private  relation,  a  user  would  enter: 

Define{  Private,  ‘‘Contents”,  NewRel{}  }; 

Finally,  we  need  a  means  for  manipulating  groups  of  rules  as  a  unit;  this  is  the  rule  denotation  and  has  the 
form: 

«  compound  -  rule  i .  compound  -rule  j.  ■  •  •  compound  -  rulen  .  » 

Notice  that  each  compound  rule  is  terminated  by  a  period.  (A  compound  rule  is  simply  a  rule  that  may 
contain  elses.) 

There  follows  an  fl,  session  to  declare  an  abstract  type  manager  for  stacks.  The  first  group  of  com¬ 
mands  defines  the  relations  that  characterize  stacks.  Next  comes  a  rule  denotation  containing  the  rules 
for  managing  stacks.  Finally,  a  group  of  definitions  make  certain  of  the  relations  public,  but  with  res¬ 
tricted  capabilities. 


STACKS  IN  0, 


Define  {Private,  “Contents”,  NewRel{}}; 

Define  {Private,  “Push”,  NewRel{}}; 

Define  {Private,  “Pop",  NewRel{}}; 

Define  {Private,  “Destroy”,  NewRel{}}; 

Define  {Private,  “NewStack”,  NewRel{}}; 

Define  {Private,  “Rules”, 

«*Push(A  ,X  ,S  ),  *Contents(  Y  ,5 )  =s>  Receives(A  ,S ),  Contents(cons(X  ,  Y ),  S  ). 

*Pop(A  ,5  ),  *Contents(X  ,5 )  =>  ReceivesJA  ,first[ X  ]),  Contents(rest[.Jf  ],5  ). 

*NewStack(A  ),  *Avail(S )  =*■  Receives(A  ,5  ),  Contents(nil,5 ). 

*Destroy(A  ,S  ),  *Contents( X  ,S )  =*  Receives(A  ,X).  »  }; 

Activate  {Rules}; 

Define  {Public,  “Push”,  AddOnly{Push}}; 

Define  {Public,  “Pop”,  AddOnly{Pop}}; 

Define  {Public,  “Destroy”,  AddOnly{Destroy}}; 

Define  {Public,  “NewStack”,  AddOnly {NewStack}}. 

S.  Second  Form 

The  second  form  of  fl  attempts  to  achieve  a  more  natural  notation  by  permitting  relations  to  be  named 
by  templates.  For  example,  we  can  denote  the  Contents  relation  by  the  template: 

-  is  contents  of  - 

Then,  instead  of  using  the  notation  ‘Contents(X  ,S )’,  we  can  write  ‘X  is  contents  of  S’.  Using  the  more 
mnemonic  ‘list’  and  ‘stack’  in  place  of  'X  ’  and  ‘5’  yields  ‘list  is  contents  of  stack’.  Finally,  Hj  promotes 
readability  by  allowing  the  use  of  “noise  words”: 

a  list  is  the  contents  of  the  stack 

Here,  ‘a’  and  ‘the’  are  noise  words  inserted  to  improve  the  continuity  of  the  clause. 


Relations  that  are  intended  to  be  called  as  procedures  should  have  ‘does’  as  the  first  word  in  their  tem¬ 
plate.  For  example,  the  template  for  the  Push  relation  is: 

—  does  push  —  on  — 

Inquiries  and  assertions  to  this  relation  are  made  in  the  usual  way,  by  filling  in  the  blanks: 

the  agent  does  push  the  thing  on  the  stack 

However,  the  relation  can  be  called  synchronously  by  omitting  the  first  argument  and  the  word  ‘does’ 
(thus  converting  the  declarative  into  an  imperative): 

push  the  thing  on  the  stack 

This  is  analogous  to  the  H|  notation 

Push  {thing,  stack) 

which  is  equivalent  to 

Push  (agent,  thing,  stack) 

Templates  that  do  not  begin  with  ‘does’  cannot  be  called  as  procedures. 

An  inquiry  or  assertion  is  negated  by  placing  the  word  ‘not’  after  the  first  word  in  the  template,  for 
example, 

the  list  is  not  the  contents  of  the  stack 
The  same  rule  applies  to  ‘does’  templates: 

the  agent  does  not  push  the  thing  on  the  stack 

The  structure  of  rules  in  0}  is  the  same  as  in  fl],  except  that  all  rules  are  preceded  by  ‘When’  and  the 
word  ‘then’  replaces  the  arrow  ‘=*’.  The  flj  cancellation  symbol,  “’,  is  replaced  by  the  word  ‘given’  in 
flj  In  other  respects  the  syntax  of  fl}  closely  follows  that  of  fl|. 
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STACKS  IN  n, 

Define  private  name  is  contents  of  — ”  to  be  make  new  relation; 

Define  private  name  does  push  —  on  — ”  to  be  make  new  relation; 

Define  private  name  does  pop  — ”  to  be  make  new  relation; 

Define  private  name  does  request  a  new  stack”  to  be  make  new  relation; 

Define  private  name  does  destroy  — ”  to  be  make  new  relation; 

Define  private  name  “Stack  Rules”  to  be 
the  rules 

When  given  an  agent  does  push  a  thing  on  a  stack 
and  given  a  list  is  the  contents  of  the  stack 
then  the  agent  does  receive  the  stack 
and  the  appending  of  the  thing  and  the  list 
is  the  contents  of  the  stack. 

When  given  an  rgent  does  pop  a  stack 
and  given  a  list  is  the  contents  of  the  stack 
then  the  agent  does  receive  the  first  element  of  the  list 
and  the  rest  of  the  list  is  the  contents  of  the  stack. 

When  given  an  agent  does  request  a  new  stack 
and  given  a  thing  is  available 
then  the  agent  does  receive  the  thing 
and  nil  is  the  contents  of  the  thing. 


When  given  an  agent  does  destroy  a  stack 
and  a  list  is  the  contents  of  the  stack 
then  the  agent  does  receive  the  list. 

end  rules; 


Activate  the  Stack  Rules; 

Define  public  name  does  push  —  on  — ” 
to  be  an  add  only  version  of  does  push  —  on  — 

Define  public  name  does  pop  — ” 
to  be  an  add  only  version  of  does  pop  — 

Define  public  name  does  request  a  new  stack" 
to  be  an  add  only  version  of  does  request  a  new  stack”; 

Define  public  name  does  destroy  —  ” 
to  be  an  add  only  version  of  does  destroy  — 

4.  Third  Form 

The  D,  syntax  makes  an  additional  step  in  the  direction  of  a  more  natural  notation:  the  provision  of  ana¬ 
phoric  reference.  To  explain  this  we  need  some  grammatical  terminology.  First,  phrases  which  denote  a 
value  or  object,  such  as 

a  list 

a  brother  of  Joe 
the  owner  of  the  file 
something  which  is  moving 
that  which  receives  the  result 

are  called  noun  phrases.  Second,  phrases  that  describe  a  state,  condition  or  relation,  and  normally  stand 
after  a  form  of  the  verb  to  be,  such  as 

hot 

less  than  100 
between  20  and  50 

are  called  adjective  phrase s.  Finally,  phrases  that  describe  a  state,  condition,  relation  or  action,  and  either 
do  not  contain  a  form  of  to  be,  such  as 
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moves 


does  pop  the  stack 

does  not  push  the  object  on  the  stack 
connects  the  terminal  to  the  processor 

or  contain  a  form  of  to  be  followed  by  a  noun  or  adjective  phrase,  such  as 

is  a  list 

is  less  than  100 
is  not  the  brother  of  Joe 
is  something  which  is  moving 

are  called  verb  phrases. 

A  few  simple  examples  will  illustrate  the  idea  of  anaphoric  reference.  Suppose  that  we  have  the  fol¬ 
lowing  inquiries  in  the  cause  part  of  a  rule: 

T  is  a  terminal  and  T  is  available 

Anaphoric  reference  permits  this  to  be  written 

a  terminal  is  available 

The  indefinite  determiner  ‘a’  before  the  noun  ‘terminal’  implies  an  inquiry  of  the  form  ‘T  is  a  terminal’. 
Furthermore,  the  use  of  the  phrase  ‘a  terminal’  in  the  clause  ‘a  terminal  is  available’  implies  that  it  is  the 
same  terminal  T  that  is  available.  In  essence  use  of  the  phrase  ‘a  terminal’  implies  the  existence  of  an 
object  or  value  X  having  the  property  '  X  is  a  terminal’. 

More  specifically,  the  indefinite  determiners  ‘a’  and  ‘an’  before  a  noun  N  are  equivalent  to  X  and 
generate  an  inquiry 

X  is  N 

Thus,  the  clause  ‘an  N  VP’,  where  VP  is  a  verb  phrase,  reduces  to  the  two  clauses  ‘ X  is  N  and  X  VP’. 
The  same  rule  applies  even  if  the  noun  is  followed  by  arguments.  For  example,  the  inquiries 

X  is  a  brother  of  John  and  X  is  moving 


can  b«  written 


&  brother  of  John  is  moving 

Note  that  anaphoric  reference  requires  flt  to  distinguish  between  nouns,  adjectives  and  verbs. 

We  turn  to  a  more  complicated  example.  Suppose  we  have  the  inquiries: 

T  is  a  terminal  and  T  is  available  and  T  is  not  broken 
Anaphoric  reference  permits  this  to  be  written: 

a  terminal  is  available  and  the  terminal  is  not  broken 

The  use  of  the  definite  determiner  ‘the’  in  the  phrase  ‘the  terminal’  guarantees  that  the  terminal  in  ques¬ 
tion  is  the  same  one  referred  to  earlier  in  the  rule. 

Definite  determiners  are  also  permitted  in  the  effect  parts  of  rules.  For  example,  the  rule 

When  T  is  a  terminal  and  given  T  is  available  then  T  is  allocated. 

can  be  written 

When  given  a  terminal  is  available  then  the  terminal  is  allocated 
The  phrase  ‘the  terminal'  in  the  effect  part  refers  to  the  same  terminal  mentioned  in  the  cause  part. 
Finally,  Q*  provides  a  limited  ability  for  subordination.  For  example,  the  inquiries 
X  connects  the  terminal  to  the  processor  and  X  is  not  busy 

can  be  written 


something  which  connects  the  terminal  to  the  processor  is  not  busy 

In  general,  if  VP  is  a  verb  phrase,  then  the  clause  ‘something  which  VP’  is  equivalent  to  X  and  generates 
an  inquiry  of  the  form  'X  VP’.  In  other  words,  the  clause 


reduces  to  the  two  clauses 


something  which  VP  VP' 


1 


*  VP  and  X  VP' 


Similarly,  the  phrase  ‘that  which  VP’  refers  back  to  something  X  in  a  previous  inquiry  of  the  form  lX 
VP’.  Indeed,  the  phrase  'a/an  NP’  can  be  considered  an  abbreviated  form  of  ‘something  which  is  NP’, 
and  ‘the  NP’  can  be  considered  an  abbreviated  form  of ‘that  which  is  NP’. 

Another  permitted  form  of  subordination  is  illustrated  by  the  following  example.  The  inquiries 

a  channel  is  connected  to  a  device  and  the  device  is  not  busy 

can  be  written 

a  channel  is  connected  to  a  device  which  is  not  busy 

In  general  the  phrase  ‘NP  which  VP’  is  equivalent  to  NP,  but  generates  the  additional  inquiry  ‘NP  VP’. 
The  use  of  anaphoric  reference  and  subordination  eliminates  almost  entirely  the  need  for  variable  names  in 
rules. 

The  stack  example  is  almost  identical  in  fij  and  Qt: 

STACKS  IN  0, 

Define  private  noun  “contents  of  — ”  to  be  make  new  relation; 

Define  private  verb  “does  push  -  on  — ”  to  be  make  new  relation; 

Define  private  verb  “does  pop  — ”  to  be  make  new  relation; 

Define  private  verb  “does  request  new  stack”  to  be  make  new  relation; 

Define  private  verb  “does  destroy  — ”  to  be  make  new  relation; 

...  remainder  as  in  0}  ... 

6.  Fourth  Form 

The  two-dimensional  D  syntax,  (14,  is  based  on  the  idea  of  form*.  These  can  be  thought  of,  and  are 
displayed  like,  paper  forms  with  fields  that  can  be  filled  in  with  values.  In  particular,  a  relation  is  con¬ 
sidered  to  be  a  blank  form  (i.e.,  a  template),  and  each  tuple  in  a  relation  is  considered  to  be  a  filled  out 
instance  of  that  form. 

Users  can  explicitly  create  or  delete  form  instances,  that  is,  add  or  delete  tuples  to  or  from  relations, 
by  selecting  a  form  name  (relation  name)  from  a  menu  and  filling  in  the  fields  of  the  form.  This  is  a  very 


natural  mode  of  operation  for  offices  and  similar  environments.  To  demonstrate  this,  we  use  a  form- 


oriented  terminology  to  describe  the  syntax  of  fi*. 

A  rule  is  represented  by  a  rule  window  labeled  with  the  rule’s  name: 

I  rule  name  I 


If  the  rule  is  part  of  a  compound  rule,  then  the  right  half  of  the  rule’s  title  chains  to  the  alternative  rule: 


rule  name  t 

else:  rule  name} 

rule  name  t 

else:  rule  namet 

rule  name  | 


Each  rule  window  is  divided  into  two  frame*,  an  upper  situation  frame  (the  cause)  and  a  lower  action 
frame  (the  effect): 

name 

situation 


action 

The  situation  frame  is  occupied  by  sero  or  more  condition  pane*,  which  represent  the  presence  or  absence 
of  form  instances  (tuples  in  relations).  A  condition  pane  has  the  format: 


relation  name 


field-  name ,:  field—  pattern  t 
field-  name  field-  pattern  t 

field-  name „  :  field-  patternn 

This  kind  of  condition  pane  tests  for  the  pretence  of  the  specified  form  instance  (tuple). 

The  field-  patternt  can  be  either  constants  or  variables.  If  they  are  constants  then  the  pane  will  only 
match  a  form  instance  in  which  that  field  is  filled  in  with  that  value.  If  the  field-pattern  is  a  variable, 
then  the  variable  can  be  either  unbound  or  bound.  If  it  is  unbound,  then  it  will  match  any  field-value, 
and  will  become  bound  to  that  field-value.  If  it  is  bound,  then  it  matches  only  the  value  to  which  it  is 
bound.  Field-patterns  can  be  left  blank,  which  has  the  effect  of  filling  them  in  with  new,  unique,  unbound 
variables.  Thus,  blank  field-patterns  are  considered  “don’t  cares”  since  they  match  anything. 

The  absence  of  a  form  instance  is  indicated  by  appending  the  modifier  ‘(absent)’  to  the  form  (rela¬ 
tion)  name: 

relation  name  (absent) 

field-  name  t :  field-  pattern , 
field-  name  s:  field-  pattern  t 

field-  name,  :  field-  pattern,. 

Similarly,  to  test  for  the  presence  of  a  form  instance,  and  delete  the  form  instance  when  found,  we  append 
the  modifier  ‘(delete)’: 


relation  name  (delete) 

field -  name field-  pattern , 
field-  name  field—  pattern^ 

field- name*:  field- pattern* 

Finally,  there  is  a  special  condition  pane,  called  a  constraint  pane,  which  can  appear  in  the  situation 
frame: 


There  can  be  any  number  of  constraint  pane  in  the  situation  frame;  they  must  all  evaluate  to  true  for  the 
rule  to  apply. 

The  action  frame  is  filled  with  a  number  of  transaction  panes.  A  transaction  pane  can  have  four  for¬ 
mats:  creation,  deletion,  procedure,  or  sequential  process.  A  creation  pane  has  the  form: 


relation  name 

field-  name  j: 

field-  value j 

field-  name  j: 

field-  value  j 

field-  name m  : 

field-  value * 

This  calls  for  the  creation  of  the  specified  form  instance.  The  field- values  are  expressions  used  to  compute 


the  values  for  the  fields. 


A  deletion  pane  calls  for  the  deletion  of  the  specified  form  instance: 

relation  name  (delete) 

field-  name  field—  value  t 
field-  name  2:  field-  value  2 

field-  name.  :  field-  value,, 

The  third  kind  of  action  pane  is  a  procedure  or  call  pane: 

relation  name  (procedure) 

field-  name  t:  field-  value  j 
field-  name  2:  field-  value  2 

field-  namem  :  field-  value. 

This  calls  for  a  synchronous  call  of  the  specified  relation.  That  is,  the  form  instance  is  created,  which 
requests  some  action  to  be  performed.  The  rules  containing  the  procedure  call  is  not  considered  complete 
until  the  completion  of  the  requested  action  is  acknowledged  via  an  ‘Acknowledgement’  form. 


The  last  kind  of  transaction  pane  is  a  sequential  process  pane: 


Sequence 

1: 

statement  i 

2: 

statement  2 

n 

statement 

The  statements  are  executed  in  the  order  listed.  They  may  be  either  the  names  of  rule  windows,  or  fl 
rules  in  one  of  the  linear  forms  (0,,  fij,  or  fl*). 


Finally,  we  need  a  means  for  manipulating  groups  of  rules  as  a  unit;  this  is  the  rule-group  window: 


Rules:  group  name 


For  example,  a  request  to  activate  a  rule  group  will  activate  all  the  rules  named  in  that  group 
A  specification  of  the  stack  example  in  fh  follows. 


STACKS  IN  n4 


Rules:  Stack  Rules 

Push  Rule 
Pop  Rule 
New  Stack  Rule 
Destroy  Stack  Rule 


Push  Rule 

Push  Request  (delete) 

Stack  Contents  (delete) 

From:  A 

Stack:  S 

Item:  X 

List:  Y 

Stack:  S 

Ack  now  ledgement 

Stack  Contents 

To:  A 

Stack:  S 

Concerning:  S 

List:  appending  of  X  and  Y 

Pop  Rule 

Pop  Request  (delete) 

Stack  Contents  (delete) 

From:  A 

Stack:  S 

Stack:  S 

List:  X 

Acknowledgement 

Stack  Contents 

To:  A 

Stack:  S 

Concerning:  first  of  X 

List:  rest  of  X 

New  Stack  Request  (delete) 

Available  Object  (delete) 

From:  A 

ID:  S 

Acknowledgement 

Stack  Contents 

To:  A 

Concerning:  S 

Stack:  S 

List:  nil 

Destroy  Stack  Rule 

Destroy  Stack  Request  (delete) 

Stack  Contents  (delete) 

From:  A 

Stack:  S 

Stack:  S 

List:  X 

Acknowledgement 


To:  A 

Concerning:  X 


Dialog 


27:  Activate  Stack  Rules; 

28:  Define  public  Push  Request  to  be  create-only  Push  Request; 

29:  Define  public  Pop  Request  to  be  create-only  Pop  Request; 

SO:  Define  public  Destroy  Stack  Request  to  be  create-only  Destroy  Stack  Request; 
SI:  Define  public  New  Stack  Request  to  be  create-only  New  Stack  Request; 
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APPENDIX  A:  ABSTRACT  SYNTAX  OF  0 


Session  =  statement  -  list 

statement  -list  =  <statement~list;  statement ;  statement  - list ?  > 
(  nil 


statement  -  list  f  = 


V 


-lilt} 


statement 

I  <else;  rule  ;  statement  >\ 
statement  =  1  . 

^<rule;  cause  f  ;  effect?  > I 

compound  -  rule  =  <cpd;  rule  ;  statement  f  > 


statement 


{ 


nil  \ 
stataientl 


rule  =  <rnle;  cause  ;  effect?  > 
cause  -  ccause;  condition  ;  cause?  > 


cause? 


.  ) 
/ 


condition  = 


< present;  inquiry  > 
< absent;  inquiry  > 
<  cancel;  inquiry  > 


inquiry  =  cinquiry;  primary  ;  tupl  -  pattern  > 

(  <tupl;  pattern  ;  tupl  -patter 
tupl  pattern  -  ^  <arbtnpl;  pattern  ;  pattern  : 

tupl -pattern?  =  _pattern) 


pattern  = 


j  free-variable\ 
^  expression  J 


( “U  \ 

free- variable  =  1  .  .  ^  i 

'  l  <var;  string  >  I 


effect?  = 


f nil 


) 


effect  =  < effect;  transaction  -,  effect?  > 


< assert;  predication  > 
<deny;  predication  > 

transaction  =  1 


predication 


<predication;  primary,  argument if  > 


(nil  \ 
argument.?  =  ^  orgumenttf 

argument.  -  < arguments;  erpre««»on  ;  argument.?  > 


call  =  < call;  primary  ;  argument.?  > 


.eg  -  block 


<seq  block;  itatement  -  lilt  > 


ezpre.iion 


<binop  ;  ezprenion  ;  ezpre.iion  > 

<unop  ;  ezpre.iion  > 

primary 


binop 


( 

or 

and 

eq 

ne 

It 

gt 

le 

ge 

sum 

dif 

prd 

quo 

mod 

/ 


“n°P  =  {neg} 


primary 


'  <con;  value  > 

<8ejfref;  var  > 

<var;  itring  > 

<apply;  var  ;  argument.  > 
<eval;  ezpre.iion  ;  ezpre.iion  > 
hit 
call 

k<mle  den;  itatement  -  hit  >  , 


lilt 


f  lilting 

I  <cons;  ezpre.iion  ;  ezpre.iion  > 


lilting 


{ 


nil 

<\iat  jezpre..ion  ;  lilting  > 


APPENDIX  B:  SYNTAX  OF  D, 


Session  -  itatcmcnt  -  lilt  . 


itatemcnt  -  lilt  ~  statement 


itatement 


rule  else  itatement 
[cause  =»]  effect 


rule  =  cause  =s>  effect 
cauie  =  jif]  condition  , 


condition  = 


inquiry 


inquiry  -  primary  (  tupl  -  pattern  ) 


tup l  -  pattern 


pattern  ,  •  •  • 
pattern  :  pattern 


pattern  - 


free-variable 

expression 


free- variable  =  J  ... 

1  variable 

effect  -  [  transaction  ,  ■ 


transaction 


assertion 

denial 

call 

seq  -  block 


assertion  =  predication 

dental  ~  -  predication 

predication  =  primary  (  arguments  ) 

call  =  primary  {  arguments  } 

arguments  =  \ezpression  ,  ■  ■  ■  ] 

seq  -  block  -  {  statement  -  list  } 

expression  =  [ expression  V  ]  conjunction 


conjunction  =  \con  junction  A  |  [ ~ '  ]  relation 


r 


t. 


n 


relation  =  [timplez  relator  |  timplez 
relator  =  {=|*|<|>|$|>} 

timplez  =  \timpltz  {+ |  -Jjterm 


term  =  [term  {*  |  /  |  %}]  factor 

V 


factor 


primary 


primary  =  primitive  [:  primary  ] 

/ 

eonitant 
[6  |  variable 
primitive  |  argument t 
primitive  =  |  (  ezprettion  ) 

l  ezprettion  ,  •  •  • 


conttant  = 


'  ^expreeeton  :  ezprettton^ 
call 

rule  -  denotation 


digit  + 

ehar) 


) 


nil 


rule  -  denotation  =  «  {  compound  -  rule  •>'  » 


-23- 


A  f 


I  ililT 


1  ' 

. 

L* 

■ 

APPENDIX  C:  SYNTAX  OF  D, 

—  ■  « 

5ej««on  --  statement  -  list 

5 

statement  —list 

=  statement  ;  •  •  • 

-  ■  4 

j  rule  else  italemenll 
«<aferrient  -  ^|cau#e  then]  effect  J 

compound  -  rule 

=  rule  j  else  statement  ] 

L  *  “i 

rule  =  cause  then  effect 

§1 

cause  -  When  condition  and  -  ■  • 

condition  =  [given]  inquiry 

* 

H 

J  word  [not]  \ 

inquiry  =  \noise  -  word  ]  primary  -  pattern  i  d(Kfg  |notj'  worJ  word  [tupl  -  pattern  j 

< 

9 

primary  -  pattern 

j  frcc-variablc\ 

~  1  primary  J 

*  4 

■ 

free-  variable  = 

(  anything! 
^  variable  J 

3 

tupl  - pattern  = 

(  pattern  { word+  pattern  }  l 
^arbitrary  pattern  J 

— 

I 

j  variable  \ 

pattern  -  l  •  f 

r  l  ezprtBBionj 

';-V- 

* 

noise  -  word  ~ 

{ a  [  an  ( 

the  } 

“  m 

effect  =  [tran*actton  and 

•'I 

•■. 

predication 

• 

transaction  = 

call 

► 

-;■ 

seq  -  block 

■** 

predication  =  [ 

noise  -  word 

/  word  [not]  ^ 

]  Primary  ^do<B  ^  word  [ arguments  ] 

• 

• 

call  =  [ noise  - 

word  ]  word 

f  [ arguments  ] 

*  _■  1 

arguments  =  expression  {word*  expression} 

■*V*\ 

;.>V< 

9 

seq  -block  =  begin  statement  -list  end 

■ 

i- 

. 

expression  =  [ expression  or]  conjunction 

-  4 

■  Ky 

> 

eon  function  = 

\eon function  &  J  [not]  relation 

.■  ■  *  * 
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W.  V."  **_' 

*.•  V  V  V  .*  .*  *.•'.*  * 

.\V  v  v  v  w  \*  v  v  -  *  -  * .  ;*  ,*»  >  . »  ^  ;  V  .*»  V  .*  . 

relation  =  [ simpler  relator  |  simplex 

relator  =  {=|#|<|>|$|^} 

simplex  =  [simplex  {+  |  —  )\  term 


term  =  | term  {*  |  /  |  %}]  factor 

“f 

factor  -  _  primary 

primary  -  primitive  | :  primary  j 
/ 

constant 
[ownj  variable 
word  *  of  arguments 
primitive  =  |  (  expression  ) 

f  expression  ,  •  •  • 

I  {expression  append  expression 
call 

rule  -  denotation 


) 


digit + 
f  char\ 

constant  -  \  1  ,  /  -  ,f 

nil 

rule  -  denotation  =  rules  {  compound  -  rule  .  }  end  rales 


l 


APPENDIX  D:  SYNTAX  OF  fl. 


Session  =  statement  -list  . 
statement  -  list  -  statement  ;  •  •  ■ 
rule  else  «tatement\ 


statement  = 


(; 


[cause  then}  effect J 
compound  -  rule  =  rule  [  else  statement 
rule  -  cause  then  effect 
cause  =  When  condition  md  •  •  • 
condition  =  [given)  inquiry 


inquiry 


noun  phrase  verb  -  phrase 


determ  noun  arguments  [which  verb  -phrase 


noun  phrase  = 


/ that  ^ 

\  something/  whlcfa  verb  -^rMe 


expression 


verb  - phrase 


verb  [not)  arguments 
does  jnotj  verb  arguments 


is  [not 


j  noun  -pArase^ 
\adj  -  phrase  f 


ad  j -phrase  =  adjective  arguments 


j  prep  -  phrase 

arguments  =  |  ... _  .  .. 

^arbitrary  variable i 


iable} 


prep  -  phrase  =  [preposition  |  noun  —  phrase 
effect  =  [fran«actton  and  •  •  ■  ] 


fran«arfion  = 


/  J  \ 

declaration 

call 

seq  -  block 

\  t 


declaration  =  noun  -  phrase  verb  -  phrase 
call  -  verb  arguments 


seq  -  block  -  begin  «tatement  -  list  end 
expression  =  | expression  or]  con  junction 


conjunction  =  | conjunction  (f  ]  (not]  relation 
relation  =  [simplex  relator  ]  simplex 
relator  =  {=|*|<|>|^|£} 

simplex  =  ( simplex  {+  |  -  }j  term 
term  =  j term  {*  |  /  |  %)]  factor 


factor  =  II  primary 


primary  =  primitive  [:  primary] 


primitive 


constant 
[own]  variable 
primitive  [arguments  ) 

(  expression  ) 

I  expression  ,  •  •  •  I 

I  ^ expression  append  expression j 

call 

rule  -  denotation 


digit  * 


constant  =  1 


('.‘“j' 


rule  -denotation  =  [the]  rules  {  compound  -  rule  .  }*  end  rules 


determ  =  <  an 
the 


=  word " 


ver6  =  word  * 


adjective  =  word + 
preposition  =  word  * 


APPENDIX  E:  SYNTAX  OF  0« 


Seaton  = 


itatcment  -  hit  = 


compound  rule  = 


or 


Dialog  f 

statement  -  list  | 


1:  n,->la(emcn(| 
2.  fl,-  itatement, 

n  :  n>-  itatemcntn 


cause  -  condition  * 
condition  = 

name  |  [modifier  )  ] 
name,:  pattern, 

name, :  pattern „ 


(If  the  field  names  are  first  and  rest,  then  the  pattern  matches  the  first  and  rest  of  an  arbitrary  tuple.) 
/  delete  \ 

modifier  = 

( variable  \ 

pattern  -  t- etpressionj 

effect  =  transaction 

f  nonsequential 1 
transaction  =  j 


nonsequential  = 


kind 


( 


delete 

procedure 


name  |  [kind)  ) 
name,:  fl,- expression, 

name,:  fl,—  ttpression,, 
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sequential  - 


rule  -  denotation 


Sequence 
ttatement  —  list 


Rules:  name 


APPENDIX  F:  INCOMPATIBILITIES  WITH  MCARTHUR  PROTOTYPE 


Ther«  are  a  number  of  minor  syntactic  incompatibilities  between  the  dialect  of  0,  implemented  by  the 
Me  Arthur  prototype  and  that  described  in  this  report. 

1.  To  simplify  parsing,  the  keyword  if  is  required  on  all  rules  with  a  nonnull  cause. 

2.  The  lexical  representation  of  ‘  is  and  strings  are  surrounded  by  the  ASCII  double  quote  sym¬ 
bol. 

S.  Additional  degenerate  forms  of  rules,  such  as  ‘if  eauie  =♦’,  are  permitted. 

4.  A  user  can  enter  multiple  lenioni,  each  terminated  by  a  period.  The  period  calls  for  the  execution  of 
all  statements  in  that  session.  The  semicolon  statement  termination  does  not  cause  execution. 
Rather,  the  statements  are  saved  until  the  next  period. 

5.  The  McArthur  prototype  does  not  distinguish  between  statements  and  compound  rules.  The  result  is 
that  it  is  possible  to  activate  rules  with  an  empty  cause  part. 

6.  Arbitrary  expressions  are  permitted  as  transactions. 

7.  The  object-oriented  language  f)  is  augmented  with  an  applicative  sublanguage.  To  support  this, 
statements  include  function  declarations  of  the  form: 

function  variable  |  /  ormali  ]  :  compound  -  expression 

where 

(  variable  ,  •  •  ■  1 

f  ormali  -  ^  variable  :  variable j 

and 

compound  ~  cxpreiiion  =  eond  -  expression  else  ■  • 
cond  -  ezprciiion  -  [if  expression  =■»)  ezpreuion 

8  Mutually  recursive  functions  are  declared  by  means  of  a  “forward”  declaration: 

function  /  [  ]:  nil, 

function  g  [•••]:■••  /  •  •  ; 

function  /[••■):•••  g  ■  ; 

This  ensures  that  /  is  bound  before  it’s  used  in  g ,  and  that  g  is  bound  before  it’s  used  in  /  . 
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